In the year of 2013, Google company put forward the QUIC protocol, which realized the reliable transmission based on the UDP. The protocol is realized in Google Chrome, which is mainly committed to accelerating the access speed of the web page. As QUIC protocol is the application layer protocol based on UDP, it has higher efficiency when processing the packet loss and the initial connection. QUIC mainly solves two problems of the traditional TCP (Transmission Control Protocol). Firstly, the traditional TCP is the ordered transmission, which means that in TCP, if a packet loses, the subsequent packets can not submit the data to the application layer until the lost packet is retransmitted. However, UDP supports disordered transmission. If a packet loses, the subsequent packets can directly submit the data to the application layer for processing instead of waiting till the lost packet is retransmitted. Secondly, the traditional HTTPS (Hypertext Transfer Protocol Secure) protocol needs 1 TCP handshake connection of RTT (Data Packet Round Trip Delay) and 2 TLS (Transport Layer Security) connections of RTT. However, QUIC protocol only needs 0 handshake connection of RTT at the soonest to reach the same security as that of HTTPS.
In the test, it is found that in the environment with high bandwidth and high round trip delay, the transmission performance of QUIC is relatively bad, for which the main reasons are that: Firstly, the default congestion control algorithm adopted by QUIC protocol is cubic (cubic growth curve). Cubic is a kind of congestion control algorithm based on packet loss. As the cubic algorithm adopts the cubic growth curve which can quickly reach the congestion window value when packet loss happens last time after packet loss, improving the throughput rate under high bandwidth and high round trip delay product. However, cubic judges the network congestion situation based on the packet loss mainly, which cannot accurately judge the current network status. At the same time, its target window value only changes when packet loss happens, which cannot reflect the current network status in time. Also, under the environment with high bit error rate, the congestion window of cubic will reduce sharply, which cannot fully utilize the bandwidth. Secondly, in QUIC protocol, a maximum limitation 200 of it on the congestion window is founded. That means however big the bandwidth delay product is, it can only transmit 200 packets once at most, which has relatively big influence on its transmission performance. If the congestion windows of QUIC protocol are not limited, the congestion window will infinitely increase and the severe packet loss phenomenon will happen, which will make the throughput capacity of QUIC protocol worse.
Under the environment with long round trip delay and high bit error rate, using the congestion control method based on RTT such as TCP-Westwood and TCP-Vegas can improve the transmission performance of the data. TCP-Westwood evaluates the current bandwidth through measuring the returned interval time of ACK (confirmation) and the data size confirmed by ACK and modifies the slow start threshold value to the current bandwidth value when packet loss happens. However, TCP-Vegas mainly obtains the actual throughput rate and expected throughput rate through the minimum RTT and the RTT of current smoothing estimation and evaluates the queuing situation of the current queue in accordance with the different of both to evaluate the current network situation. However, in the actual environment, as the evaluation on RTT will be affected by a lot of noises, larger difference will appear, which will affect the change of the congestion window.